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Response to a Non-final Office action under 37 C.F.R. 1.111 

Summary of the p rosecution 

20 Applicants filed an RCE in the above application with a Submission that amended the 
claims to overcome a double patenting rejection on the basis of the closely related 
application US SN 09/3 12,740 and in order to gain rapid allowance for their claims. In so 
doing, they were not and are not conceding either that the rejection in the final Office 
action that preceded the RGB on the basis of Knoth, Tools for a collaborative World, 

25 Computer Aided Engineering, April 1997, 9.40-47 was proper or that the claims were 
anticipated or rendered obvious by U.S. patent 6^442,557, Buteau, et al. Evaluation of 
enterprise architecture 'model including relational database, filed 2/27/98, which was 
cited in the prosecution of USSN 09/3 12,740 and was cited by Applicants in the present 
application. Applicants are consequently retaining their right to file a divisional 

30 application with broader claims than the ones presently contained in this application. 

In his first non-final Office action in the RCE, mailed 1 1/30/2006, Examiner made no 
further mention of the double patenting rejection, rejected claim 43 under 37 G.F.R. 
1.75(c) as an improper dependent claim, and rejected all claims under 35 U.S.C. 103 as 
35 obvious oyer the combination of a new reference, U,S. patent 6 ? l57j 915, Bhaskaran, et 

7 Method md apparatus for c supply chains, filed Aug. 7, 
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1998 and issued Dec. 5, 2000 (henceforth "Bhaskaran"), and Official Notice. Applicants 
are traversing the rejections. 

Traversal 

5 The rejection of claim 43 

This claim is a dependent Beauregard claim, i.e., it is a claim to a data storage device 
such as a mass storage device or a storage medium such as a CD-ROM that is 
characterized by the fact that it contains a program which, when executed, implements a 
system claimed in an apparatus claim or a method claimed in a method claim. The 
10 patentability of any Beauregard claim is necessarily completely dependent on the 
patentability of the method or apparatus whose implementation code is stored on the 
storage device. 

Applicants' attorney has been writing and the USPTO has been allowing such dependent 
15 Beauregard claims for at least 10 years. The statutory provision governing dependent 
claims is 35 U.S.C. 112, fourth paragraph, which requires only that the dependent claim 
"contain a reference to a claim previously set forth and then specify a further limitation of 
the subject matter claimed". Claim 43 satisfies the foregoing requirement: it refers back 
to claim 37 and claim 37 is further limited by the fact that what is claimed is not the 
20 system of claim 37, but rather a storage device that contains code which implements the 
system set forth in claim 37. Because claim 43 is permitted by 35 U.S.C 112, 4th 
paragraph and 37 C.F.R. 1.75(c) and the relevant MPEP provisions merely restate the 
statutory requirement, Examiner's rejection is without basis. 

25 Overview of Applicants' system for supporting management of a collaborative activity 

Since Examiner is new to this application, Applicants respectfully refers Examiner to the 
overview of the goal, domain, and initiative hierarchies which may be found at page 25, 
line 6 through page 29, line 10 of Applicants' Specification and to the overview for the 
graphical user interface for the system, which is shown in FIG. 46 and discussed at page 

30 36, line 11 through page 39, line 15. Claim 37 and its dependent claims are to be read 
and interpreted in light of the usage of claim terms in the overview. Important claim 
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terms include "model", "model entity", "goal model entity", "initiative model entity", 
"goal hierarchy", "initiative hierarchy", goal model entities that belong both to a goal 
hierarchy and an initiative hierarchy, and a user interface which permits "persons [who 
are not] specialists in information technology" to perform operations on model entities 
5 such as assigning them to a parent in a hierarchy and viewing the model entities in their 
hierarchies. 

The disclosure ofBhaskaran 

Bhaskaran discloses a system for collaboratively managing supply chains. FIG. 1 shows 
10 a graph of an example supply chain. It should be pointed out here that there is no 
indication in the disclosure of Bhaskaran that there is any representation of the supply 
chain graph of Fig. 1 in Bhaskaran's system or display of the supply chain graph in 
Bhaskaran's user interface. It should further be pointed out that the supply chain graph of 
FIG. 1 is not a hierarchy. In a hierarchy, a given node may have only one parent node. 

15 

The graphical user interface of Bhaskaran's system consists of "active documents", i.e., 
interactive screens in a Web browser. The active documents are domain task specific and 
access to the active documents is based on the role of the user in the supply chain. When 
an event occurs which requires reworking of one or more aspects of the supply chain, 
20 active documents are sent to the appropriate role players for their inputs. See col. 2, lines 
33-46. FIGs. 2-8 present examples of the active documents. 

FIG. 9 is a flowchart of the operation of the system. The operation is described at col. 7, 
line 40-col. 8, line 10. In overview, the supply chain is optimized by applying a Supply 

25 Capability Engine (SCE) to a scenario that describes a state of the supply chain and 
publishing a plan based on the supply chain as optimized for the scenario. When an 
event that affects the supply chain occurs, the role players are informed via the active 
documents of the event and use the active documents to cooperate in making a new 
scenario that takes the cause of the event into account. Once made, the supply chain is 

30 optimized for the new scenario. A number of iterations may be performed. When the 
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iterations reach a satisfactory result, a new plan is made that is based on the final 
optimization of the supply chain. The new plan is then published to the role players. 

The rejection of Applicants' claim 37 
5 Claim 37 as amended in the Submission that accompanied the RCE reads as follows: 

1 37. (new) A system for supporting management of a collaborative activity by persons 

2 involved therein, the persons not being specialists in information technology and the 

3 system comprising: 

4 a representation of a model of the collaborative activity, the representation 

5 being accessible to a processor, the model of the collaborative activity including 

6 model entities that are organized into hierarchies and provide access to information 

7 concerning the collaborative activity, 

8 the model entities having types including 

9 a goal model entity type, model entities of the type representing goals 

10 and/or projects of the collaborative activity and 

11 an initiative model entity type, model entities of the type serving to 

12 relate goal model entities across the model, and 

13 the hierarchies including 

14 a goal hierarchy whose members include at least one goal model 

15 entity, a given goal model entity belonging to only a single goal hierarchy and 

16 an initiative hierarchy whose members include at least one initiative 

17 model entity, each initiative model entity being capable of having as children one or 

18 more initiative model entities and/or one or more goal model entities from one or 

19 more of the goal hierarchies; and 

20 a graphical user interface for the system which the processor provides to the 

21 persons, the graphical user interface permitting a person of the persons to perform 

22 operations on a model entity including creating, modifying, and/or deleting the model 

23 entity, assigning the model entity to a parent in a hierarchy, accessing and/or 

24 modifying the information concerning the collaborative activity via the model entity, 

25 and viewing model entities in a hierarchy of the hierarchies to which the model 

26 entities belong. 
27 

Examiner's rejection of the claim is made under 35 U.S.C. 103 and is based on the combination of 
Bhaskaran and Official Notice that "the representation [of the model] [is] accessible to a processor". 
30 In order to make a rejection under 35 U.S.C. 103, Examiner must make a prima facie case that 
includes a demonstration that the combined references disclose every limitation of the claim under 
rejection. See MPEP 2142. In the present case, that means that Bhaskaran must disclose every 
limitation of claim 37 other than the limitation that "the representation [of the model] [is] accessible 
to the processor". 



4 



beavenO 1.002 



When the foregoing summary of the disclosure of Bhaskaran is compared with claim 47, it is 
immediately apparent that many of the limitations which Bhaskaran must disclose if it is to serve as 
a basis of a rejection under 35 U.S.C. 103 are in fact not disclosed by the reference. To present 
5 some examples: 

The representation of the model of the collaborative activity 

As already pointed out, the supply chain graph of FIG. 1 is not the "representation of the model" of 
the claim. The closest thing there is in Bhaskaran to a representation of the model of the 
10 collaborative activity is the plan. There is no disclosure in Bhaskaran of the form of the plan, but 
since it is published (FIG. 9, S980), it appears to be a document. The plan certainly does not 
include "model entities that are organized into hierarchies", as required by the claim. 

Model entities 

15 There is in fact nothing in Bhaskaran that can be regarded as a model entity. Bhaskaran's active 
documents are used to inform users of Bhaskaran's system of events that may require 
reoptimization of the supply chain and to enable the users to collaborate in making the scenarios 
that are the basis of the reoptimization, but they are clearly not model entities. There being no 
model entities, there can also be no model entities that have the goal model entity type or the 

20 initiative model entity type, as required by the claim. 

Hierarchies 

There being no hierarchies in Bhaskaran, there can be no goal or initiative hierarchies and a goal 
model entity cannot belong both to a goal hierarchy and an initiative hierarchy, all as required by 
25 the claim. 

The graphical user interface 

Because there are no model entities disclosed in Bhaskaran, there can be no graphical user interface 
which permits a user to perform operations on a model entity. In particular, because there are no 
30 hierarchies of model entities in Bhaskaran, there can be no operations of assigning a model entity to 
a parent in a hierarchy, of accessing and/or modifying the information concerning the collaborative 
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activity via the model entity, or of viewing the model entities in a hierarchy to which the model 
entity belongs, as required by claim 37. 

Patentability of claim 37 

5 Because Bhaskaran discloses none of the foregoing limitations of claim 37, Examiner has not made 
his prima facie case of obviousness and his rejection of claim 37 under 35 U.S.C. 103 as obvious 
over Bhaskaran and Official Notice is without foundation. Further, because claim 37 is patentable, 
so are all of the claims that are dependent from claim 37. 

10 Independent patentability of certain dependent claims 

From the foregoing discussion, it will be immediately clear that Bhaskaran also discloses nothing 
corresponding to domain model entities and domain hierarchies, as set forth in claim 38, or a 
display having "a first part in which the model entities of the hierarchy are viewed and a 
simultaneously visible second part in which a model entity selected by the user from the hierarchy 

15 is viewed", as set forth in claim 39, access to information via any of the model entities, as set forth 
in claim 40, per-model entity access control, as set forth in claim 41, or viewing model entities as 
ordered by a value to which the model entities give access, as set forth in claim 42. Because these 
claims set forth limitations that are not disclosed in Bhaskaran, they are patentable in their own 
rights over the combination of Bhaskaran and Official Notice. 

20 

Detailed rebuttal of Examiner's rejection of claim 37 

Examiner finds the claimed representation of a model in FIG. 1 and its description at col. 3, lines 
42-59; the figure is simply a graph of the supply chain; there is no indication in FIG. 1 itself, the 
cited location, or anywhere else in Bhaskaran that FIG. 1 shows "a representation of a model of the 

25 collaborative activity, the representation being accessible to the processor". Further, because FIG. 
1 is not the claimed model, the nodes of the graph cannot be the claimed model entities; finally, as 
already pointed out, the graph of FIG. 1 is not a hierarchy. For goal model entity types, goal model 
entities, and goal hierarchies, as well as initiative model entity types, initiative model entities, and 
initiative hierarchies, Examiner refers Applicants to col. 3, lines 60-67, col. 4, lines 14-29, and FIGs. 

30 1 and 5. What is described at these locations is how the supply chain of FIG. 1 works, why it is 
necessary for the participants in the supply chain to exchange information, and how the roles of the 
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participants in the supply chain determine their access to Bhaskaran's active documents. None of 
this has anything to do with model entities, model entity types, and hierarchies as they are described 
in Applicants' Specification and set forth in claim 37. 



5 Examiner finds claim 37s graphical user interface at col. 5, lines 10-49, col. 6, lines 7-45, and 
FIGs. 2-4 of Bhaskaran. FIGs. 2-4 simply show examples of active documents; FIGs. 2-3 are 
described at col. 5, lines 10-49 and FIG. 4 is described at col. 6, lines 7-45. As may be immediately 
seen from a comparison of Applicants' FIG. 46 with Bhaskaran's FIGs. 2-4, Bhaskaran's graphical 
user interface does not permit anyone to perform an operation on anything that can be compared to 
10 Applicants' model entities or on hierarchies of model entities, as required for Applicants' graphical 
user interface. Indeed, the fact that at this point, Examiner takes Bhaskaran's scenarios to include 
model entities only underlines the difficulties inherent in Examiner's rejection of claim 37. 



Conclusion 

15 Applicants have traversed all of Examiner's rejections and have thereby been completely responsive 
to Examiner's non-final Office action of 11/30/06 as required by 37 C.F.R. 1.111(b). Applicants 
consequently respectfully request that Examiner continue with his examination, as provided by 37 
C.F.R. 1.111(a). No fees are believed to be required for this response. Should any be, please 
charge them to deposit account number 501315. 

20 

Respectfully submitted, 

/Gordon E. Nelson/ 

Attorney of record, 

25 Gordon E. Nelson 

57 Central St., P.O. Box 782 
Rowley, MA, 01969, 
Registration number 30,093 
Voice: (978) 948-7632 
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